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LEN SHUSTEK: 

[Initial portion not on videotape] ... eventually opening a public museum, focused on the history of computers, hardware, 
software, documentation and so forth, designed for adults, not a kids' hands-on museum, but it's an adults-onented 
museum. It's a long term project; we're probably going to take four or five years to get there: to build a building, to find a 
location, and site, and so forth. In the meantime we're focusing on continuing to build the collection, which is the finest in 
the world. It's got thousands of artifacts, and thousands of photographs, and documents, and books, and so forth. 

We're inviting people to help us with this project by doing lots of things. We have weekend volunteer days, when people 
come and help us work on the collection. We'd like as many people as can to become members of the museum, and you 
can do that in several ways. One program, that we just started, is that you can become a member for a hundred dollars, 
and get a card that gives you access to the History Center, and also gets you access to Moffett Field. So on Wednesdays 
and Saturdays you can, without going through the process you went through today, get onto the Field and to have access to 
our visible storage location. 

In addition, for about the next six months, you have an opportunity, one-time only, to become a founding member of the 
History Center, by donating a thousand dollars or more, and be permanently enshrined as one of the founders of the 
Computer History Center. It's the same kind of program that was done by The Computer Museum 10 or 12 years ago when 
it was in its founding stages. 

What else are we doing? We are mounting a bunch of exhibitions in vanous places. We've done several at trade shows and 
conferences. We've got one that's going to be opening next week at the new Gates Computer Science Building at Stanford, 
where we're taking part of our collection and showing it off. And until we have our own permanent space, that's a good way 
to show off some of our wares. 

We've got more stuff coming. As we speak, there are four tractors being loaded in Boston and heading across the country 
with the next installment of the machines and part of the artifacts from Boston. Included in there is the JOHNNIAC, and the 
CM-5 Thinking Machine that we just got from MIT, and a whole bunch of other very valuable artifacts. 

If you want to get more information about the Computer History Center, talk to me or Gwen Bell or Joey or Dag, or any of 
the other people who are on staff. We'd like to thank the people at NASA Ames here for their hospitality, both in the use of 
this conference center, but also in the use of the warehouse space, for which we're very much in debt to them. There are 
some flyers in the back that you can pick up, that descnbe what's going on here, both NASA generally and their Center for 
Excellence in Information Technology. 

This is one of a senes of talks that we've been giving, in cooperation with the Bay Area Computer History Perspectives. 
Peter Nurske runs that, and he will introduce tonight's speakers. 

PETER NURKSE: 



Thank you, Len. I don't really run the Bay Area Computer History Perspectives. It's more a joint venture between myself - I 



work at Sun Microsystems - and Jeanie Treichel, who also works at Sun Microsystems. Jeanie was at Xerox PARC, many 
years ago, as part of history herself. 

We started this computer talk series over four years ago, back in [1993], and two of our speakers at the first program are 
here in the front row: Norm Hardy and George Michael, from Livermore. So a lot of people have been coming back over the 
years, from one program to another. Larry Tesler, who's one of our two speakers tonight, himself did a program along with 
Bob Herriot, Larry Breed, Don Wise, over three years ago, on the Stanford card stunts, which I wrote up in the description 
[as] the largest bit map display ever. You know, it was like several thousand students holding up colored cards in sequence. 
That was a feat itself, to do the programming of instructions, back then at that time. 

Larry has also been coming to many of the programs before and since then, so it's like this history talks series had 
developed a history of its own. So, tonight we have Larry and Chris Espinosa from Apple, talking about the early Apple user 
interfaces. I think, as you may have heard, Larry came to Apple from Xerox PARC, back in 1980, and he figured he was 
bringing a lot of user interface knowledge with him, only he's found out recently that user interface testing and development 
existed at Apple before 1980. And Chris had a part in that. Chris ~ I think this is correct ~ was probably the youngest Apple 
employee ever; [he] did demos at Apple while a high school student. 

So, Larry .... 

LARRY TESLER: 

We're glad to be here. This is a talk actually that's based on one that Chris and I gave at Apple back in July. We got 
clearance, thankfully, from the Apple lawyers, which came about two - three weeks ago, so we could give it here, just in 
time to announce it. We're grateful to Apple to release this for public disclosure, because we think it's of general interest. 

Asking about what was early user interface design at Apple was kind of like asking about early engine design at Mercedes 
Benz or something. Everybody was doing it. So, you could have gotten a lot of people up here to give a talk, and you get 
different perspectives on the same things that happened. So today you're going to get the perspective of a couple of us. 

To get it to be a little more grounded in something more [closely related] to fact than opinion or perspective, we're trying to 
use as much as possible actual, original documents that were created at the time. So you see actual, contemporaneous 
thinking as it was going on, instead of just our memories, which fade over time and tend to aggrandize over time, and so on. 

Here's something which is not from Apple. This is the cover of Byte [Magazine], from August '81 , that was the Smalltalk 
issue. Colorful ~ this one doesn't have color, but it was a very colorful balloon. The reason I show it is that there was a lot of 
influence from Xerox obviously on the user interfaces that were done on the Lisa and the Macintosh, but maybe not as 
much as some people think. The media tends to say, "Oh, they just copied it." So I'm going to show you what it looked like, 
to be working on, from that article, which I wrote, to be working on a Smalltalk, at that time, 1981. You see what the 
windows looked like, kind of a little rectangular title, scroll bar without any arrows, and a pop-up menu. There were two pop- 
up menus that you could use for each window. So, it was a pretty different looking interface. 

One of the principles that was in the Smalltalk environment was to have no modes, and this was actually of a tee shirt that 
was made for me by a friend, that said "Don't Mode Me In", that represented sort of this mission that I was on, to try to 
eliminate all modes from user interfaces. Which isn't necessarily a good idea, but it was definitely the mission I was on. 
[Laughter] 

And at the end of that article, it mentioned that Apple Computer had gotten a license to Smalltalk, and was maybe going to 
do something with it, but maybe not going to do anything with it. In fact, Apple, and Hewlett Packard, Digital Equipment, and 
Techtronics all did do various amounts of Smalltalk development after that. But it was really independent companies that 
managed to make Smalltalk somewhat of a success. 

I'm jumping to the end here before I go to the beginning, just to let people know what the Lisa was. The idea of the Lisa 
was to have something that was very, very easy to use. People loved the Apple II, which was what we had at the time at 
Apple, but it took a long time to learn how to use it. What we wanted to end up with was something that was easy to learn, 
and just to show you that we did do that, this is a study done at the end, where there were 18 subjects: 6 using LisaGraph, 
6 using LisaWrite, and LisaList. LisaGraph was a business graphics program; LisaList was a list manager, kind of a flat file 
database; LisaWrite was a word processor. And as you see, for all but one user using LisaList, it was under 20 minutes to 
get through the core competency to use the application. And if you ever had a chance to use a Lisa, and I hope there will 
be one operating here someday, then you'll see that it was extremely easy, and in many ways more bullet proof, I'd say, 
than the Mac. Not simpler than the Mac, actually, but we loaded a lot of things into it to try to make it so people couldn't get 
themselves in trouble. 

Okay, so let's start at the beginning. I started at Apple on July 17th, 1980, and I just left there a few months ago. I was 
there for 17 years. This memo was written on July 18, 1980, so one thing I discovered when I left the big Xerox Corporation 
and went to this little Apple startup, was that you just really get engaged immediately and they put you right to work. One 
thing I was told, the day I got there, was that the user interface design was basically done, and they were just going to write 
it up and finalize it, and implement it, and that was the end of it. And it was too bad I took so long to show up at the office, 
because they were hoping that I could have contributed to it, but now there was no time left to do that. And this was the 
18th, and they told me that all the decisions had to be made by the 23rd, and by one week later the external reference 
specifications had to be done, which was the complete spec, but we couldn't compromise quality at all, and so, what could I 
do between the 18th and the 23rd, to make sure we made all the right decisions? 

So I started explaining how it was really necessary to do months of user testing, and careful iteration, and I gave my whole 
spiel about the right way to design software, and they said, "Well, sorry, we only have five days, and the weekend in there." 
[Laughter] So, we got together and we came up with a compromise, which was to lay out a schedule that was very 
aggressive, and people promised that they would meet their part. So let's go through the schedule ~ this was the 18th. 

So here was the schedule. Monday, we're going to run user tests, so — well, we're all going to try it ourselves. Everybody's 
going to try Bill Atkinson's prototype. Bill Atkinson was the person building the prototypes at that time, and thinking up a lot 
of the ideas. And we were going to evaluate several issues that were going on. Then we were going to bring in, after two 
_ ho urs of that — we were goin g to t ake a bre ak for lunch. Then at one o 'clock we were going to bring in Sue Espinosa, whq_^^^ 



was in charge of training, and also coincidentally is Ctiris Espinosa's mother, and then she was going to give her opinions 
about that, and maybe help us decide on what would be easiest to train in her opinion. And then at two o'clock we were 
going to discuss, for an hour, a couple more Issues, and now we would be done. We will have discussed all the issues. And 
in between three and five o'clock we would present this all to Steve Jobs, and Steve would make the decision, which we 
knew would be definitely forthcoming. [Laughter] 

And then on Tuesday we were going to take the things that Steve liked, and we were going to test them on subjects, from 
9:00 to 10:00. Two subjects. [Laughter] Two more subjects from 10:00 to 12:00 ~ we must have figured we'd be slowing 
down by then. [Laughter] 1:00 to 3:00, we'd evaluate the test results. 

So that was it. Remember, that was supposed to be July 22 nd. For the next 15 minutes or so, keep in mind that that was 
the schedule for July 21 st and 22nd. And we actually did that. We did all those tests. We did talk to Steve Jobs. He gave 
his opinions. We did some more testing. And then Bill went to write up a user interface specification, external reference 
specification. I was a little worried, because we hadn't really done extensive testing, but we tested a couple things. 

So this date, August 6, which as you may notice, a few days later than the deadline date that we had provided, but it took a 
while. And it said that you had one week to review and return your comments. So we were already starting to slow down a 
little bit here. And let's look at some of the names of the people who got this memo, because it will turn up to be important 
later in the story, or just interesting right now: Ken Victor, who is going to respond to it later, and Jef Raskin also. Barry 
Smith. In additon to that, notice we sent it to Mike Markkula, who was one of the founders of the company, and Steve Jobs. 
Trip Hawkins, who was the head of Product Marketing. We sent it to everybody in Lisa software group. We only sent one 
copy to Lisa hardware; they get to share. [Laughter] We sent it to every vice president we could think of, and to two people 
who became Apple Fellows somewhat later. Rod Holt and Steve Wozniak, who's here in the back today. I don't know if he 
remembers receiving this memo, but he probably does, it was pretty dramatic. 

I think we did some things right. Bill started out by talking about who is the customer. So it wasn't just some easy to use 
computer, it was an easy to use computer for specific people. So, what was it? First of all, it's a single user workstation. 
That was in important point in those days. Well, it's still an important point if you work at Sun or something. And [it was] 
designed to enhance the productivity of the office worker. So our market was office workers. And it went on and talked 
about the hardware and so on. 

It's more than a piece of hardware, though. It includes major software, and we had specific applications in mind: word 
processing, graphics, data management, and communications. It wasn't intended to run thousands of applications, not the 
Lisa. The concept that Trip Hawkins had was, they had done studies and they had found that most people, on the Apple II, 
ended up using only two or three applications. Therefore ~ this was the great leap ~ all we need to do is provide two or 
three applications, that's all anybody will ever want. It was an interesting theory, and Apple funded a whole project based on 
that assumption. 

And then it said, "The software is integrated through a powerful and simple user interface." And it doesn't say it here, but 
John Couch, who was in charge of the Lisa project, did a sort of Kennedy we're-going-to-send-a-man-to-the-moon-and- 
bring-him-back thing; he said "All I want is, I want to be able to go into a spreadsheet, put some numbers in, go and graph 
them, take the graph, paste it into my word processor document, and include it in a report." He didn't say "paste" ~ you 
know, "put it into my word processor document." He said, "[If] I can do all those things in an integrated way, then we'll be 
way ahead of anything available on the Apple II, where there are all these separate programs that don't interact with each 
other." That's all he wanted. Whenever we brought him any issue he said, "Remember what I want," and he went through 
the whole mantra. And that was a very healthy thing. It kept us focused. And then we also knew when we were done. 

Well, who were the users? Non technical, non analytical people. Non analytical. That's a very important point First time 
users. Well, in 1980 there were a lot of first time users. Almost everybody. And here were examples: administrative 
assistants and secretaries. Also, secondarily, managers, accountants, and executives. It wasn't for programmers, it wasn't 
for kids, it wasn't for people at home doing recipes, this was an office system. And so, when you start looking at it, and 
comparing it maybe with the Mac, you'll see some differences based on that. And you may see some similarities to 
Windows. 

Design philosophy: so there was a whole section on the design philosophy, and what were the most important features to 
put in? Graphic images. Well, that was pretty vague. Menus. A pointing device that you could move around freely, as 
opposed to the cursor keys we were using up to then. And, we were going to let you invoke commands from the keyboard 
also, because there were times when you would do things over and over, and people felt that sometimes the mouse slowed 
you down a bit. 

So let's look at this keyboard. This was the keyboard that existed on the hardware when I arrived. It had a Code key in the 
upper left corner, and some of the keys, on their fronts, had some characters. In other words, in order to [get] the keyboard 
width they wanted, they couldn't fit all the characters on the keys. So they squeezed a few extra characters on the fronts of 
the keys, and had a special key to invoke those. And later we decided we could use that key together with other keys to do 
another function, that you'll see later. 

Now, I didn't like the hardware design too much, and 1 wanted to change it, but they said "You can't change that. You know, 
you came from a research place. We just have to ship the hardware that we already built, otherwise we won't be able to 
ship this product when it's going to go to market." I said, "Oh, when is that?" They said, "Six months." That was 1980. To 
jump ahead, it didn't ship 'til the middle of '83. Probably my fault. Okay. [Laughter] 

So, here was the pointing device. Kind of a brick — that's a mouse. And, the color is me; I added color last night, just to 
highlight things you should look at. But it had two buttons at that time. And I handwrote on here something about the shape. 
I wasn't too happy with the shape. And I wasn't sure what distinguished these two keys, and whether there was a little 
space between them, or whether they were flush, or what. So, you'll see some of my handwritten scribbles on these memos. 

And here's how the mouse was used. Well, actually they didn't know a lot about how the mouse was used yet. They mostly 
were focused on the window manager: how the user would manage the windows on what we now call the desktop. And so 
at that time the idea was this: there would be a click and a drag, and those were two things you could do. You could click 
and let go, or you could click, hold, drag the mouse, and let go. Sometimes we called it "drag," sometimes we called it 
-"draw." vaciQus-names. And then the buttons got names: the "point" button and the "grow" button. And dependina on where^ 



you pointed, and whether you clicked or dragged, and which button you used. 

This page here shows what happens if you went into the title tab of the window, the little thing that had the name. And it 
either would display the window menu, move the window, open or close the window, or change the size of the window. All of 
it done by clicking in the title. So there was no "grow" box in the lower right, there were no menus, it was all done with just 
one of two mouse buttons and a click or drag operation. Now, there was a menu at the bottom of the window, but it had 
nothing to do with window operations. It had to do with operating on the content Inside the window. We'll get to that. 

I should stop saying "when I got there" because by then I'd already been there for two weeks, so I had some influence on 
this. I can't remember what. So here's a letter to Jef. Now "Jef is misspelled. That's Jef Raskin, who does spell his name 
that way. And he became the person who we were always sending these letters to, on the Lisa project. And, as you see, 
this scroll bar was on the left side. It had the horizontal scrolling arrows at the top, the vertical scrolling arrows at the 
bottom. Now, those of you who know the Next machine know that that's a feature, is that you have the two arrows close to 
each other so you don't have to move very far to go between the two arrows. That was actually designed in 1980 by Bill. 
And then at the bottom, the edit menu had Cut, Paste, Dupe to copy things, and Undupe. And then on the side there were 
the equivalent of today's icons. This was taken from Smalltalk, where you took the tab of the window ~ threw away the 
window, and just kept the tab ~ called it collapsing the window. And these were windows that were available but closed right 
now. And you could open them up. 

Then we had this idea of fill-in menus. Just to jump ahead, they were what we call dialog boxes today. And there were two 
kinds. There were kinds where you somehow open a sub-menu and you get to type into that sub-menu ~ don't ask me 
exactly how. The other is where it actually opens up a big box, like we know today. That was this thing called forms. And so 
it was kind of a vague notion at that time, no one had actually drawn any pictures even of what those looked like, I think. 
And again, we said that menu commands can be invoked from the keyboard, and I put a little note saying "Disagree 
somewhat." And I wish I could remember what I disagreed with. I think I was afraid they would do too much keyboard stuff. 

There were scroll bars. You would hold a button down to scroll continuously. Now, there was an interesting idea here that 
you would double-click to flip to the next page. Anybody that knows about user interface design with single and double 
clicks ~ usually you make it so that when you click once, you can start doing something, and then when the second click 
comes, it doesn't sort of negate what you already started to do. This is kind of interesting, because you clicked once, it 
would start to scroll a little, and when you clicked a second time, it would realize you wanted to jump a lot. So you'd get a 
little motion, and then a jump. That actually might have been kind of cute. I don't think we ever implemented it. 

Then there was something called the elevator shaft, with the elevator in it. And that was what is still today, that little box in 
the scroll bar that you see. There was the abbreviations window, that was that Code key. We had to find a use for it. So you 
could type Code, and then hit a letter on the keyboard, it would look up in a table and it would expand your abbreviation. 
This was the kind of thing you'd find in a Wang word processor. So we put that in, because this was for secretaries. 

Then there was something called the system error window. And that's what you now know as alert boxes, in Mac and 
Windows. And these were things that would come up when there was a problem, and it would make some kind of beep, and 
would tell you what the problem was. So I put a little question mark here. Is the system frozen when that comes up? Can 
you do other things? And we eventually decided it was modal, but actually that took quite a while to decide. 

Now, we talked about testing. We said that the design's already based on studies of user reactions to various models; as 
you saw, we did three or four hours of testing. [Laughter] And we're going to do more testing, and avoid any glaring design 
flaws. I was happy that that was put in, because that meant we could go and fix some more problems that I was sure were 
there, because we hadn't done enough testing yet. 

So, what did it come down to? This is what it looked like: the basic model was overlapping windows, which is right from 
Smalltalk. There was that box at the top, just like in Smalltalk, that little title bar. The scroll bar was on the left, just like in 
Smalltalk, only instead of just that little box, there were the scroll arrows there. We thought it would be nice to have 
something to point to. In Smalltalk, you push the button and then the arrows appeared, and we thought that was a little 
weird. And there was this menu at the bottom. Now, if any of you ~ who's ever used the system called UCSD Pascal? If 
you remember, there were menus in UCSD Pascal, and you would type the first letter of the menu name, and it would bring 
up a sub-menu, and you'd type the first letter of menu name, and you go through a hierarchy of menus. 

Now, also there was a machine — I'm going to forget the number ~ a Hewlett Packard computer, 2000? [Inaudible 
comment] No, it was a later model than that. HP something thousand, that had a row of function keys on the top of the 
keyboard, and at the bottom of the screen, under each key [comment: still have it?] Still have it. And you'd hit that key, that 
would activate that menu item. These were the two products that the authors of this interface knew the best. They used 
UCSD Pascal to do their software development, half of them came from Hewlett Packard, and so this was kind of a blend. 
And so they had function keys at the top of the keyboard that you could hit that would invoke the corresponding things, and 
they also had these hierarchical menus that were straight out of UCSD Pascal. Not the little pop-ups that were in Smalltalk. 
So that's where it was in August. 

Cut and Paste were two of the commands in the menu; that came from Smalltalk. And, as you see, there was a 
wastebasket. That's what you call the clipboard today. We used to call it the wastebasket. Different from the trashcan, which 
was a confusion we had later, and that's why we changed the name. But when you cut something, it went in the 
wastebasket, like in the office, you cut something and throw it in the wastebasket. But then you could take it and paste it 
somewhere else, and it was sort of a weak metaphor. And so you'd select it with a mouse. Notice that when you selected, 
there's this little arrow here. That turns out to be a significant point later. 

I'm moving fast because there are a lot of slide here. Now, Ken Victor, remember — is Ken here today? No? Ken was one 
of the reviewers of the document, and he provided some input, very quickly. And he said, "Why can you only select with a 
mouse?" He must be someone who used EMACS or something; he wanted you to be able to select from the keyboard. You 
know, fourth line, third word, seventh character ~ should be able to specify what you want. And fourth occurrence of the 
word Lisa, you should be able to say things like that. And he was maybe either — he sort of didn't get it, or he was years 
ahead of his time, whichever way you want to look at it. But this is what he would like to use, and we had to sort of explain 
to him that our target market didn't want to find the fourth occurrence of Lisa in the third paragraph. They could see it with 
their own eyes, and select it with the mouse, and that was just fine. 



^ Now, here was something I wish we had listened to. At this point, it said that you were growing windows from the lower 

right. I showed you something before showing that it grew at the top. I think in this document it was sort of ambiguous, 
whether you grew it from the top or the lower right. And he didn't like that idea. He wanted to be able to grow from any side. 
I do think that's better, and we didn't pay any attention to him. They were worried about the screen space being too tight, or 
something. 

Moving a document within a window: he wanted to know, whether we could do what we now call live scrolling. As you move 
that elevator up and down the shaft, he wanted the text to move continuously. Problem was that the Lisa processor ran at, 
what, a quarter? [Comment: Five megahertz.] Five megahertz? It didn't even seem that fast, to me. Couldn't do it. So, some 
things were just pragmatic. 

He didn't like the idea of Cut and Paste. He wanted us to use Move, Copy and Delete, and Transpose. In other words, say 
you have two things you would select, move this to there, copy this to there, transpose these two things. Well, this wasn't 
the first time I'd heard that argument, and in fact this is one of those religious arguments like one button or ~ one versus two 
buttons. Do you want Cut, Copy, Paste? Do you want Move, Copy, Delete? The reason we went for ~ well, you can argue 
for either one. It is two steps to do Cut and Paste. But there are a lot of advantages to it. One is that Move and Delete sort 
of start with the same thing. Some people think that's good, some bad. Another reason is that you don't have to be able to 
see the destination when you are copying or cutting the source. That's the most important thing. And on a screen of limited 
size, when you have windows overlapping, it's sometimes very hard to get them all lined up, so you can specify two targets. 
Where you have windows popping up and down, you get very confused. 

The other thing is, that I had a secret agenda, which is, I thought the machine should be used not for what they talked 
about, office systems. I thought, well, that was good, but I don't want it to be used just for that. I thought it would be a great 
machine for publishing, and that we'd be able to do Cut and Paste to do page layout, which was my own personal interest. 
And so I was advocating that because that's definitely the way you'd want to do page makeup. 

But we did user testing, and the users slightly preferred the cut and paste model. The wastebasket window was able to not 
only have one thing you cut out, but multiple things you cut out, and he had some comments about how to deal with the 
multiple items. Some of us thought it should only hold one; he thought it was okay to have multiple ones, and he lost in the 
end. 

Okay, here are some comments from me. I was complaining because nowhere in the spec did it say what the response time 
should be. It said all about the user, what they'd do with it, but it never said that this needs to respond within half a second, 
this needs to respond within two seconds, that needs to respond within ten seconds. It never said it anywhere, and I was 
worried if it didn't say it, the engineers wouldn't do it. And if any of you have ever used a Lisa, well, it was really slow. I lost 
that argument. They said "It'll be as fast as we can make it." And that was too slow. 

And then it talked about a really interesting question, which was, well, we want hierarchical menus, and we want keyboard 
accessible commands, so we seem to be fixated on the way they do it in UCSD Pascal: you type a key, get another menu, 
type a key, get another menu. And that just bothered me, and I thought there's a lot of mistakes going to be made. People 
are going to forget which level of the hierarchy they're in, how they get back out of it again, it's just going to be too 
complicated. And I didn't like it. 

So — we'll come to how that was solved later. The other thing I was complaining about was the two-button mouse. We didn't 
use the second button for much else for a lot of different things. We didn't use it for much. And when we did, there was no 
way to remember which button did what. And so, I wanted to eject the second button and just have one. And that's August 
13th. 

Operations on windows. I proposed here that we have this box in the lower right hand corner, that we used for growing the 
window, instead of doing it from the top. And also I thought there ought to be a way to split a window into panes. And then I 
had a whole section here about moving a document within a window. I go and talk about the scrolling and why I don't like 
the way it is. And then I said, "Why don't we put one arrow at the top of the scroll bar, one at the bottom of the scroll bar?" 
And I actually prototyped it. 

Those of you who know the Xerox Star know that the Xerox Star had that feature. Those of us who were from Xerox were 
under a confidentiality agreement, that we weren't allowed to tell the other Apple people about the Star. And so, as you go 
through this, you'll sometimes find that things seem like, "Isn't it obvious solution? You could have got it from the Star." But 
none of us were able to say how the Star was. We were only allowed to comment on other people's proposals and make 
new ones. And it was an interesting kind of dynamic. But, gradually over time, a few Star-like things crept in, but not many 
until the Star actually shipped, or it was announced, in June of '81. But here we are in 1980. 

Then I suggested we try an I -shaped cursor for text selection, instead of an arrow. It actually is something I had done in my 
early years at Xerox, in a particular word processor I had done. I also said I wished the cursor would be bigger than 16 by 
16, to go to 32 by 32, which we eventually did. 

Menus ~ this was what, August 18th? "I think we should experiment with menus at the top or right of the window, or even 
totally detached at the top of the screen, full width." So up to this time, we were doing sort of the way Windows does, and 
' every window had its own menu. And I was thinking, "You know, maybe we ought to put it at the top." You'll see why in a 

minute when you see the pictures. And then I said, "Hierarchical menus ~ well, maybe we have to have them, we can't get 
rid of them, but could we make them mouse accessed instead of having to type all these keystrokes?" So, these were my 
two causes of the moment. 

Barry Smith, who was in Product Marketing, responded about the same time. And he said - at this point, Bill had moved the 
menu bar, that Edit Cut Copy Paste thing, from the bottom of the window to the top of the window. That was the change. 
And Barry liked that. He liked it a lot better near the top. Called it "near the top." And then he wanted to know, though, what 
would happen if there were a lot of menu items, and could the menus scroll. And those of you who know the history of the 
Mac user interface, know that at some point, around 1990 or so, we started adding scrolling to Mac menus. But we didn't 
' have them in the early Mac or the Lisa, and I was against it because that would have encouraged people to have a lot of 

menu items, and I didn't think they should. So I kept that from happening. You can't constrain people, though. 
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we could get to something where it was a single keystroke to invoke a command no matter where it was in the hierarchy. 
And I think Bill was experimenting with that at that time. And he also didn't like the two-button mouse. He thought it was 
confusing. 

So, August 18th ~ I guess that was August 13th, before. A few days later, after intense political, polite discussions, heated 
sometimes. Bill and I decided "Hey, let's get rid of the second button. Let's shake things up. One-button mouse." So we 
wrote this memo together, so that people knew we were real serious. Sent it to the usual suspects. And we say, "We 
recommend a change to a one-button mouse." And whoever wrote this comment, and I'm glad I don't know who it was, 
said, "Well, maybe, not sure that's a good idea." But it turned out that Trip Hawkins, who later went on to found Electronic 
Arts and 3D0, was the Product Marketing manager. He loved it. He said, "That's what we've got to do. We've got to think 
more kind of consumer oriented, really simple, get rid of all this computer science concepts, and give people something real 
simple." He liked the one button. 

So after that, we had a period, sort of, of good will, where we were able to do user interface design without a lot of 
complaining. Which ended after a while, as you'll see. 

Well, if you only have one button, some things are hard to do. You can drag a short selection, but what if you want to select 
something three pages long? It's a long time to drag from one end to the other. So, we thought, okay, well, we'll use the 
Shift key on the keyboard, because this doesn't happen very often. You click the beginning of the selection, you'll scroll to 
where you want to go, hold down the Shift key, and click the end of the selection. So that's where we got the Shift-button 
thing. Adjusting selection. 

And then we said, "The one-button mouse is superior. Look at the reasons: superior human factors, you don't have to think 
of a name for each button." [Laughter] That's important, when you're trying to ship product in six months. The mouse will be 
cheaper to make, because one less button ~ I mean, just think of what the cost of that little switch is. And, something a little 
more profound, someday when we start having other things than mice on our computers, like joysticks for games, tablets, 
touch screens, we'll be glad we only had one button because that one finger or whatever or pen that the user is using is the 
button. That turned out to be sort of prophetic, although very few such pointing devices take advantage of that, in fact. They 
usually have buttons anyway. 

Okay, so August 22nd, this is a revised version of the user interface, and it says, "This is it, now. We're done." So now, 
instead of a week, you only have three days to return comments, because we must be done. There couldn't be more than 
one or two comments; they're probably just typos or something, by this point. We'd been working on this interface for a 
month, already. 

Okay, so what did it have in this version? It had a concept called "dimmed highlighting." This was introduced for the first 
time, that I know of, here. That if some of the menu items, instead of eliminating menu items that weren't relevant, which ~ 
we would dim them, we would gray them out. Instead of being black type they would be kind of in gray type. And then we 
said, "They can be invoked any way the user wishes, although they wouldn't do anything." And we were also going to use 
dim highlighting for another purpose, which was to show toggles. And as you know, that was later changed to have 
checkmarks, instead of just using this for two purposes, because that was very confusing. But at that point we thought we'd 
get away with one mechanism for both things. And it was Occam's Razor: if one mechanism will do, then don't have two. 
Well, it turned out that one didn't do, so, we had to apologize to Occam. [Laughter] 

Now, as you know, you can do command keys on the Mac or Lisa keyboard, and you can invoke commands from the 
keyboard. And we knew it was important to reserve some for the most common commands, because it might be okay for an 
application to use Command Shift J for something, but we wanted to be sure Cut, Copy, Paste, Undo were the same for 
everybody. Bold, Italic, Underline, and Normal ~ we thought these would be used the most. And so, the whole sequence ~ 
I'm not going to go through them all today, but we had various theories, and as you see here, it's rather different from what 
we ended up with. Z X C D was sort of the order on the keyboard; Cut Copy Paste Undo was the order on the menu, so 
that was it. Over time we refined this. This led to many very heated arguments. People would rather argue about trivial 
things like this than important things, but we did have fun arguing. 

Does anybody remember what they really are? Today? [Comment: Control-I, Control-V] That's right, Control-I, Control-V, 
and then for Cut? [Comment: Control-X, the same as Wordstar!] Wordstar? Oh, I didn't know that. [Comment: That's part of 
the problem of most computing, is people don't realize what...] Well, we did X because it was a cross-out, and we did V 
because it pointed down like this, and you were inserting, like an upside down caret. [Laughter] That was Paste. And Z was 
the closest one, because we figured you'd Undo a lot. And C for Copy, that was easy. So that's how we did that. 

So this was the anatomy of a window. We had title tab, and notice, next to the title tab, we now move the menu to the top. 
As was commented upon, someone obviously had got a sneak preview draft, and that earlier memo. And look, there are 
menus that are popping down from the menu bar, first time. When it was at the bottom, it didn't make a whole lot of sense, 
but now that it was at the top. Bill could, instead of having the menu come here and replace the previous menu, like it did in 
UCSD Pascal, he could use the second dimension and have a menu pop out to the bottom. Don't ask us how we're going 
to do third-level menus, but at this point, this was good enough. We had two levels of menus, and we were happy. 

Over here, there was the elevator shaft. Now we called it the thumb instead of the elevator, because we wanted to have 
horizontal scrolling too, and elevators in those days didn't go horizontally, although Scientific American says they're about 
to. And then we had continuous scrolling arrows, and notice the arrows point this way, but when you click on these arrows, 
the text was going to move that way, as opposed to the other way, which is what it does now. And that was an interesting 
argument, that I think I have covered here too. 

We had active folders, so we had to have passive folders; the folder that wasn't active was passive. Now look at the 
bottom. Who has ever seen Mac OSS? And when you drag a window to the bottom of the screen it just kind of pops, and 
becomes just a tab, and then you can click it and it will slide open. Guess what? That was in the original design, in August 
1980, that we were going to do on the Lisa. And it only took 17 years to implement. [Laughter] [Comment: Microsoft's doing 
a similar thing.] Microsoft did something sort of similar, but not really the same, in between. There are some differences, but 
I won't comment right now. 

So what happened if the window was narrow? Well, if the window was narrow, this shows that the menu wouldn't fit; it 
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^ to the bottom of the screen, then it would do this. And so, Bill showed all the cases, and a lot of us weren't too happy with 

this. So I went back to Bill again, and I said, "Bill, the top of the screen - top of the screen!" None of us liked the idea of a 
two-line menu, which is the way Microsoft solved it, in some version of Windows. 

Here's an example of a menu item being selected. Notice that he's now got highlighting of the menu title, and he's got 
highlighting of the menu item. Bill had a long night one night and came back with that. And we had the help menu in here. 

The way we operated was, that Bill spent every night programming, and the next day we would do testing and arguing. I 
don't know when he slept, actually. Did he sleep? And then he would do it again, every night. 

Here's a memo from Gail Pilkington in Publications. The people writing manuals for the Lisa were key in commenting on the 
user interface design, had a lot of suggestions and a lot of good criticisms. And Gail actually had been at Xerox before. So, 
she said, "I don't like pull-down menus. [I] think they're ugly, and they cover things up." So, you know, I'm trying to cut 
something, and the first thing that happens is the menu comes down, and covers the thing I'm trying to cut. No good. 

And then Bill had this feature, that you could ~ which he still has - you could drag the mouse along the menu bar, and the 
menus would pop up one at a time. And we thought this is great: the user can see all of the available commands in one 
swoop. Well, she thought it was terrible, that you had to do that to see all the commands. I didn't understand, because in 
UCSD Pascal you had to hit keys for 10 minutes to see all the commands. So, I didn't quite get that. 

She also didn't like the idea of dim highlighting. She thought we should just suppress the items altogether. So we had 
dissent in the group. And we always had dissent in the group. I just chose that because it's a memo that I had, illustrative of 
dozens of people who had dissent over every issue. Nothing specific about Gail. In particular, she said, "Last version the 
spec, I thought we only had one issue, which was when that little menu bar at the bottom was full, we didn't know what to 
do about it, and you should have just solved that, instead of moving it to another place, adding drop-downs, and all these 
other things. You over-designed to solve the problem. And besides, I don't like Z for Cut and X for Paste." She had her own 
proposal that was mnemonic. 

September 22nd. It was now a month after I first said, "Bill, why don't you try at the top of the screen?" Bill had a very long 
night, and came back with the menu at the top of the screen, with command keys, check marks, everything ~ he had 
everything. In one night he invented the entire mechanism of the menu bar at the top of the screen. To me it was just a 
place to put what he already had, but once he realized it was there, he could do a lot of other things. And he implemented 
an amazing amount in one night. 

So he wrote a memo to justify it, and said, "There are some problems with it. You have to go way further to reach the menu, 
that's a problem." But we decided, since there were command keys, and he made it very easy to have a single-stroke 
command key in this version, this all-night version, that okay, if you really wanted to go to that menu item a lot, you could 
hit the command key on the keyboard instead and you wouldn't move the mouse at all. So that solved that problem. The 
other problem was, that if there were a lot of windows open, you wouldn't really be sure which menu applies to which 
window, and sure enough, that's still true today. But, tradeoffs, you know. Why was it good? It was good because you got rid 
of all those ugly cases of sticking out menus, and also, the dialog box that came up when you had a command with 
parameters, could always go in the same place. And we had a problem before, with the dialog box coming up and covering 
up the menu, half the window, and so on. And so we could put it in a standard place under the menu bar. 

So this was all the result of his long night of invention. And then, a couple more examples, we could put some global 
commands in the menu. Before, we didn't - we hadn't figured out yet where to put the global commands. They didn't really 
go anywhere, because every menu was in a window, but now having a menu at the top, we could have global commands 
like shutting down or whatever. And then we could widen the title tabs, because the menu didn't take up room at the top of 
the window. 

Now we're in February '81, so we've leapt ahead now several months, where all the programmers are busy implementing 
stuff. They're designing an operating system, telling us that we're holding up the project when they're still designing the 
operating system. I was in charge of the Applications Group, and we're the reason the project is behind schedule, even 
though they still were designing the operating system. 

So I wrote a memo for other people who were going to help out with user testing. I made guidelines for user interviews. So, 
never argue with each other in front of the interviewee. After they leave, you can shoot each other, it doesn't matter, but not 
while the subject's there. Don't patronize the subject — don't show off your knowledge. I wrote this because I would be 
bringing engineers into the room, and I'd sit them in the back. And the user would struggle to do something, and the 
engineer would run forward, jump out of the chair and run forward, grab the hand of the person, and say "It's easy. You just 
do this." [Laughter] And I'd go, "Naw, naw naw. You don't get it." So, we tried gags, we tried all kinds of things. [Laughter] 
Finally I said, "Look, I'll let you in the room if you observe these rules: Don't plant the answer. Take turns asking questions, if 
there are several of us there, so we get different ~ we may each see different things. And mainly, try to get them to do the 
talking. This is not a lecture by you, this is a test of them, and you want them to verbalize all they possibly can." 

[The] typical thing that would happen is, we'd bring somebody in, to prove that the user interface thing they put in was 
absolutely right and we were totally wrong, and then the end user would usually prove we were both wrong: both the things 
I were hard to use, and then we'd have to go back and redesign it. Or, half the time, the user would say, "Well, why doesn't it 

just work this way?" And we'd look at each other sheepishly, and fix it. 

Now here was an interesting one, for those of you who do user testing. You don't — if you don't name things, you don't just 
say, "What would you call this?" People paralyze, like "Oh, you're asking me to invent a name." They just get totally 
paralyzed, they can't thing of any. But if you say something like "If someone were to bring you this, if you wanted someone 
to bring you this, what would you say? Bring me the ... " And then people would come up with something. It actually worked 
pretty well. People have similar techniques, I've heard, for other things. 

April 3rd, '81 . Well, at this point they were starting to get very nervous about the schedule. The operating system design was 
I done, I think, and so we were holding things up. And they decided the problem was that these engineers, instead of just 

writing code like good sheep, were going and worrying about whether it was usable or not. So they decided to take all power 
away from us, and put all the decision making into a council. So who was on the council? [The] first person was the Division 
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Publications for Lisa, whicli was a good idea. Fourtti one was l<ind of the arcliitect of the group; that was a good idea. And 
the fifth one was somebody in Product l\/larl<eting, who you saw had made comments before, that were pretty good ones. 
So, I was lool<ing at this, going "Umm, ol<ay, maybe we can live with this." But the main thing they did that was very good is, 
we instituted a process for what to do If you had a user interface issue. Don't spend eight hours arguing with each other. 
Write it up, make your points, get back to work. And then we have a process for dealing with it. But, the council would rule 
by majority vote. So, I think, "What a way to design a user interface, by majority vote of the Comptroller, the Sales V.P., 
okay." [Laughter] 

But, we started. This motivated those of us who decided we had to do this the right way to actually run more user tests. 
Because we thought maybe we could overwhelm them with facts, and that will overcome this reliance on votes of 
committees. So, Chris Doerr, Wallace Judd ~ I think Wallace maybe worked at Xerox before this, I can't remember ~ these 
are two people that got involved with user testing the Filer, which we think of as the Finder today. And they ran some tests, 
and came up with all sorts of comments. I've underlined a couple here. Like there needs to be a way to select multiple icons 
at once. Well, they weren't icons yet even. Ways to manipulate multiple things at once. 

But basically, after making some comments, they said, "You know, this is a good idea." Their own personal experience with 
testing was that you hired a testing firm, you spent a lot of money, three months later you came back with test results, and 
you did some things, and you did it again. You know, it took forever. Or, they would take a book and give it to a subject. 
Have the user read the manual, try out the manual, videotape the whole thing. And she said, "You know, this wasn't bad, 
just sitting down next to the user and having a dialog with the user, trying to get the user talking, and express what they're 
doing, is not a bad way to do it." So that was good, that we got the people doing the user testing to adopt this much simpler 
and cheaper paradigm. 

We tape-recorded the sessions, and they found that useful. They went back and listened to the tapes. However, the tapes 
were hard to hear, because the people in the room were making noise. So they asked the observers to be quieter. 

But one problem, she said, was that we're only testing Apple employees. We would get Apple employees the day they took 
the job, the day they started work. We'd get them in orientation. The person running orientation would say, "Well, after 
orientation you can go straight to work, or you can go be a user test subject, and, hey, you can get out of work for a few 
more hours," so we got a lot of people to come over and be user test subjects. Almost all of them had very little computer 
experience, because although Apple would have liked to hire people with computer experience in those days, there weren't 
very many. 

Here's a typical schedule. We weren't trying to do two an hour any more. One person at a time. One each day. Nine o'clock, 
one o'clock, three o'clock, much more civilized. And we had a checklist that the tester went through, before each session: 
Have you reminded the subject of whatever ~ I've no idea, whatever they're supposed to remember, that's on the list. Is 
there coffee available? Do you have a blank questionnaire ready for the person? Because we had them fill out a 
questionnaire at the end. Do you have the checklist ready? Have you rewound the tape? Have we rewound the tape for 
this, the talk today? Have you rebooted? Because it crashed if you didn't. Are the cue cards in the testing room, etcetera. 
After each session did you cover up the Lisa again, because the room had a window, and at night you could see in the 
window, and see the secret Lisa machine. Did you close the blinds, for a double measure? Etcetera, etcetera. So we had a 
lot of things to remind the tester about. That's a good idea if you ever run user tests, have a checklist. 

Now Wallace, the guy who received the last memo, wrote this memo about some testing results. He said he spent about an 
hour a subject, which was pretty typical. That's the way I like to do testing myself. And he said, "Well, some functions still 
unclear; in particular, seven subjects out of ~ how many? It doesn't say, but not a lot, not very many ~ "most of the 
subjects had trouble with Undo Last Command. They'd never seen such a thing in a program before, and they just didn't 
quite understand what it meant." Then there were other ones they understood, but they didn't feel comfortable with 
somehow. One was Print a Copy, one was Mail a Copy. Well, I believe the reason was that we didn't have printers yet on 
the machine, and we didn't have e-mail. In fact, we never had e-mail. [Laughter] So, we're probably just showing these, and 
not really ~ couldn't use them, so of course they didn't understand them. 

Graphics editor user testing. This was LisaDraw, which became Mac Draw later, implemented by the same guy actually, 
Mark Cutter. And we wanted to test various things. Is this confusing, is that confusing? What happens if you try to use 
rulers at the same time as cross hairs? Is that too many things on the screen? Considering all the widgets that are there 
today in a Photo Shop or something, why were we worried? There was even worry about whether people could use a 
graphics program, because most people can't draw. So they wouldn't use a graphics program. 

We also wanted to know the error rates. And so a lot of counting was being done, and looking at tapes to see how many 
times people made errors, and try to reduce the error rate. So we were trying to be sort of scientific, even though we were 
on this headlong schedule. You may have noticed that six months have already gone by and we haven't shipped. In fact, it's 
about a year at this point. 

Okay, so June '81 , Pat Marriott writes this memo about validating the prototypes, and Trip Hawkins at this point is at his 
wit's end. He says, "Aren't we done with all these decisions yet? Let's get on with it! Why are we still talking?" 

Here are some of the issues. Should the arrows point apart, away from each other, or towards each other? Because, after 
all, the text moves in the direction that's opposite of the arrow direction, we could flip the arrows and make them point to 
each other. And I wrote a comment here, "Ahh, we can wait until September to test this. No hurry." I wasn't in synch with 
Product Marketing, who wanted all the decisions to be made, because I knew that changing this was a matter of about 
three minutes of programming. So what was the hurry? I'd rather work or harder issues, like getting the software to fit in 
memory, or something. 

And there were some questions about clicking in folders — oh, by the way, when you see folder here, we used to call 
windows folders. I forgot to mention that earlier; it might have been confusing here. Every window is a folder, even a 
document window was a folder. Not just the ones on the desktop. And we wanted to do some tests on that. 

[Inaudible comments from audience.] Okay, October '81. We took Chris's advice to heart ~ Chris Doerr's — and we did 
outside testing. 24 people who did not work for Apple were done in a 1 -way mirror room in Daly City. They didn't know what 
company it was that was showing it. A blind test. The psychologists had their day. We got to do this right. This was the thing 
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was going, "Well, maybe we'd better test this on real people." 



We wanted to know whether they could read the manual, and install the hardware, and get the thing running, by 
themselves. And it turned out that it was 10 minutes, on average, that a person could, from the time they opened the box, 
until the time they get set up and running something. We thought that was pretty good. Those of you who were at Apple 
later know that on the Mac, it was even easier, at the beginning, but as the Mac got more and more developed, that number 
went up. And when that number started getting about an hour, Jean-Louis Gassee got extremely upset, and he ordered new 
user tests, and they ran user tests about that, and got the time back down to 10 minutes again. But there were some bad 
years in there. It was very hard to open a Mac box and figure how to set it up. 

Two thirds of the users say they felt comfortable using the product as a result of the first experience. And about half of the 
people who were ~ half of the third that were uncomfortable were people who happened to run into crashes and so on. 
Which probably affected ~ they were trying to beat the clock on setting up the system. It was kind of frustrating. 

And we had a questionnaire they had to fill out. This is the result of the questionnaire, so those numbers are how many 
people had that answer. And they didn't think it would be that difficult to set up. Before, they started ... [few words missing 
from tape] ... after they did it, they found that it was very easy. 

All right. Now it's still 1981 , I should mention that the Xerox Star was announced at NCC or something — National Computer 
Conference, I think in June of '81. Some Lisa people flew out there, got a look at it. Bill Atkinson went, I believe, and Steve 
Jobs went, or maybe he sent Bill and didn't go himself, I can't remember. At this point we had a guy named Greg 
Stikeleather who had joined the group, working for Ellen Nold in Lisa Training. Some of you may know Greg, because he's 
more recently been an entrepreneur, sold a couple of companies. And Ellen is sending a memo to various people, copying 
Greg, on responsibility charting for user tests. Now, that user interface council we talked about before, with the majority 
vote, I don't know if they ever even had one meeting. We kind of overwhelmed them somehow. And by this time, a few 
months later, we had to have a new process. So the new process was that, based on some lecture we all went to by some 
management consultant, we were going to have people with authority, people with responsibility, people who are consulted, 
people who are informed. And basically. Product Management had all the authority, since Ellen worked for them [laughter], 
and Engineering and Training, which was Ellen's group, had all the responsibility. So we did all the work, and then Product 
Management would bless it and say that ... [portion missing from tape] 

Okay. February 1982. A year and a half has gone by. Engineering user tests. This is a sample test. This is a write-up of a 
test. We had a standard form to write them up in, now we're getting real formal here. Not just, you know, run in to Steve 
Jobs after the test and tell him what happened. We were writing formal reports: what the person did, how they did, I'll skip 
over a little bit of this. The person had to draw an org chart, and here, not having a graphics program myself that had 
printing working yet, I was doing it in the word processor and drawing little org charts here. But they were really doing it with 
a drawing program. 

And by the way, the thing that won over the Product Marketing people was when we gave them the drawing program. It was 
the first one to get working. I had Mark Cutter just try to get it really reliable, and don't worry about too many features. And 
then we gave all the Product Marketing people a Lisa, some temporary operating system, and the drawing program. That's 
it. It was a single-tasking operating system at that time. And they all started using it to make foils. You can do text, you can 
do boxes, you know, and they all did foils. They fell in love with the Lisa, and even started to understand the Lisa, and 
gradually the complaints started dying down, and they started trusting like maybe we knew what we were talking about. So 
that was a very good political move. I always made sure Mark gave them good stable versions of the Draw program. They'd 
draw a floor plan. And then at the end ... [few words missing from tape] ... had comments to make, and you could see that 
the comments were summarized, and people were basically very positive about this program. Sometimes there were 
complaints, and we addressed them. 

This particular test was, I guess, run by Greg Stikeleather and me. He probably ran the test and I was in the room, or 
sometimes we switched off. He made a comment, which was that I-beam, which was the cursor that you used to select text, 
when the person would start typing, that little cursor was covering what they were typing. So he suggested that we get rid of 
it. Well, there was no mechanism to get rid of it. in the software, but he didn't know that. So it was good that he was there, 
and suggested it. And we then implemented that. 

I pointed out that the stretch handles were a problem. Initially, what Mark had done was he studded the outside of the 
object, like every fourth pixel, with a little handle. So big objects had beads all the way around the outside. It was like a 
necklace. This really confused the people, and I suggested that we just have the four corners and the four sides, and that's 
all. And that is the way it ended up. 

Of course, I'm going to show you all the good comments. We had a lot of stupid suggestions, too. And now, remember we 
had user test guidelines before. Greg wrote some new ones. Here, he was trying to address this to people who might have 
been used to formal user testing, and never experienced what he was calling development testing ~ things you test after the 
fact, and things you test while you're still in development. So he made some guidelines, and they were interestingly a little 
different from mine. A different level. And I think I didn't bring them. Just the fact that he did. 

All right, getting near the end here. May, '82. A little less than two years since I arrived. I had just finished some tests, so 
Greg said we should run some development tests, so we did, we ran development tests. I taught 30 Apple employees, over 
a period of several weeks, several different applications, to see whether we were on the right track. By this time people 
were accepting this as a good approach, because it was a lot better to be informed by a user test than to just see who 
could talk the loudest in an argument, or who had the most political clout. 

What I found was, the way we taught it made a lot of difference. You could take the same user interface and teach it a 
different way, and people would get real confused, or understand it, or make more mistakes, or fewer mistakes. And 
terminology made a difference also. So we then started a terminology project that Ellen Nold ran, which ended up, and I 
have many slides I didn't bring on that, and that ended up with the File menu, the Edit menu, et cetera, as you know today. 
And the various commands that were in them, choosing all the words for everything, that have pretty much survived into the 
Mac. I'd say 95 percent of them survived into the Mac, and most of them went into Windows also. So that was a very 
healthy terminology exercise. We did a lot of testing, and a lot of debating, a lot of linguistic analysis. 
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ship a product, and it's been a long time since I've been at PARC, so okay, we'll ship a product. But couldn't we fix these in 
the next release? Well, little did I know there would only be one more release. 

And then we had a process, again, where we were going to be very careful about prioritizing all the user interface changes, 
and measuring their schedule impact, and being sure they were worth it. [It] didn't have to be zero, necessarily, but it had to 
be worth the schedule impact. 

I think by this time people were really realizing that our only differentiation was ease of use, and it better be really easy. And 
then I went through some problems. This thing went on, by the way, for about 30 pages, so I'm just going to show you one 
page. Cursor changes were not consistent, and there were cursors changing shape everywhere. The I-beam wasn't the only 
one, like, no matter where you went in the window, you got a different cursor shape, and I thought that's too many, let's 
simplify that. 

We had double- and triple-clicks at that time, and some people ~ it was the amount of time between the clicks mattered, 
and you couldn't control it. So I suggested we add a preference item, that people could control that time, which of course is 
what you do today in Apple's mouse control panel. And I also had some comments about how you teach it, and in fact, 
when I looked at that whole memo, I'd say there were at least as many comments I made about how to teach it, as to what 
it is. 

And then, months earlier, I think it was, maybe one month earlier, Greg Stikeleather had pointed out that the I-beam should 
disappear when you type. I don't know whether I forgot, or whatever, but I suggested the same thing again, or observed it, 
and I proposed we hide the cursor. And here in the margin is something I wrote later, saying it has been implemented. 

If you're wondering about the cursor changing to a clock, or an hourglass, various other things, that was something that was 
actually at Xerox. Xerox had that at PARC. The way we did it was, we would wait a certain number of seconds, and if the 
operation wasn't done we would put up the hourglass. Trouble was, by that time the operation was probably done, or some 
of the applications forgot to put it up at all. So we came up with some clever algorithm for having it come up automatically, 
and disappear at the right time, and all that sort of stuff. 

Now, here's the big change. The Star had come out a year earlier than this, and we were all told by management and 
ourselves, "Don't pay any attention to that. We've got a product to ship." But in everybody's heart they kind of felt like "You 
know, most of the Lisa's easier to use than the Star, but there's one thing about the Star that is really, really nice, which is 
those little icons on the desktop." There was icon envy that was very serious, and we weren't allowed to work on it. But 
around March of that year some of the guys got so troubled by it that they started working at home on weekends on an 
iconic filer, we called it. And at first it was a big secret, and they started letting people in on it a little bit at a time, and finally 
everybody found out about it, and there was a major uproar that people would dare to make changes at this late stage. But, 
they'd already implemented it. And so you couldn't complain about the schedule impact. [Laughter] 

The person writing the manual thought it was kind of a good idea, so she kept saying it wouldn't affect her schedule 
[laughter], so nobody knew what to do. So I made a deal with Trip Hawkins, and Wayne Rosing, who was the engineering 
manager at that time: we'll run user tests, and let the users decide. So I ran tests, and you know what? It turned out that the 
interface we had, which I won't bother to show you, but it was kind of more like Find File ~ that's the closest thing I can 
think of — was actually equally good in terms of ease of learning, equally easy to use, same error rate, very low, people 
understood both, there was no difference. And we already had one, so why did we change? The last question I asked 
everybody is, which did you like better? And they all liked the picture one better. And so we made a decision that had 
nothing to do with ease of use, nothing to do with ease of learning, nothing to do with error rate. It wasn't a human factors 
decision at all, in the traditional sense. It was a decision based on what customers liked. 

And there's a whole history 1 won't go into here about the icons. They didn't actually come from the Star, they came from 
something IBM did. I'm not going to get into that. Long story. You can read the proceedings of Apple vs. Microsoft lawsuit or 
something to find that out. [Laughter] 

Okay, so this is my last slide here. This was a memo that included on it Chris Espinosa, who was in the Macintosh group at 
that time. And the Macintosh people, who had been doing a totally different user interface, at some point decided they really 
ought to do some subset of the Lisa interface instead. And so they wanted to get a lot of ideas from us, as they designed 
their user interface. We started copying the Mac people on it. And with that, September '82, I'll turn it over to Chris. 

Q. You know back in the days when the arrows were the single scroll bar, did it take a second mouse button to move it in 

the other direction? 

LARRY TESLER: No, you used one for both. Why don't we, if you want, we can talk about that after the talk. 1 forgot that I 
had a videotape here ~ is that monitor turned on? What I've got here is just 30 seconds, because the tape is really bad, of 
one of the very first user tests, in July of 1980. And the one I have here. Bill and I took turns, and this one I'll be showing 
you is Bill with a subject. You can't see the subject. Most of the tape, all 1 can see is the out of focus back of Bill's head, but 
for about half a minute we can actually see the screen of the Lisa. So it's really quick, you'd better get a good look. 

[PLAYS THE VIDEOTAPE - NOT TRANSCRIBED] 

See, here's that menu at the bottom of the window, this is really early. And there's that highlighted selection the person 
made with the mouse. And he just explained something very simple, and she didn't understand it, so he's starting all over. 
And now we get to see his hair, so I think we'll stop. Okay, so there's nothing much to get out of that, but I did promise to 
show some early Lisa user tests. Now I've done it. 

Given the time, I think we're going to save questions to the end, and let Chris take off on his. Great. Thanks very much. 
[Applause] 

CHRIS ESPINOSA: 



As Larry said, the work that we did on the Macintosh human interface dovetailed with the end of the very fruitful period of 
Lisa human interface design. I cannot believe how much work they went through in a short period of months in the summer 
of 1980, to put together what we still see today in the human interface of the Macintosh, and the human interface of^^^ 



Apple, from some companies we'd acquired, on how the user interface came to be, that a lot of the people he was referring 
to, a lot of the people who are co-copied on some of the documents, a lot of the work that they drew on, really had nothing 
to do with the graphic user interface, but had to do with a long standing user interface community at Apple that had evolved 
in a totally separate organization for a totally separate strain, and that was the Apple II and the Apple III human interface 
effort that was going on in the Personal Computer Systems Division, which was by that time physically remote down in the 
big black triangle shaped building at the intersection of 280 and Lawrence Expressway, called the Triangle Building or by 
then the Bermuda Triangle, because it's where the Apple II group had been moved to die. [Laughter] 

The thing you have to understand about the crucial difference between the Lisa-Macintosh human interface effort and what 
was going on in the Apple II group was not the difference between graphic human interface and text-based human 
interface, though that was an important part of it. The crucial difference was that in the Lisa and Macintosh, the engineering 
groups were completely integrated in, and the driving forces behind, making the computer easier to use, whereas in the 
Apple II the evolution of that had been that the impetus for making the computer easier to use, and which programs were 
selected to make that, had come from the Publications Department, the Training Department, and the department doing 
demonstrations for in-store retail sales, and I was a member of that group. Out effort was primarily to mask the complexity 
of the real underlying software that we were already shipping, by putting sugared user interfaces on top of the real 
interfaces. And by putting training programs on top of the real computer programs. This was ~ remember the Apple 
computer by 1980, boy, we'd been around for three years. We had a long history behind us in the personal computer 
industry. And we had a lot of accumulated legacy software that we couldn't just haphazardly change, we really had to work 
on it. 

One of the documents that I have here is a document; I've got it on video here, although I don't think it will be that easy to 
read. 

VIDEOTAPE: ... manual is consistent and provide a consistent and familiar and productive experience to readers of 
manuals. Bruce Tognazzini took the concept of the ... [sound fades out] 

This is that document, and this is the change history of the Apple II human interface guidelines, that show the first draft 
Bruce Tognazzini claims to have written in September of 1978. A second draft in March of 79, third draft in mid-1980, fourth 
draft with Steve Smith in early 1981, and then it got into the Macintosh group in 1982. I started working on it in late '82, and 
that's when I incorporated many of the things from the Lisa efforts. And then it moved back over into the Apple II group, to 
cover the Apple II graphic user interface. But it originally started as an Apple II text human interface document. And it came 
originally from Bruce's efforts with J. D. Eisenberg, writing an application called Apple Presents Apple, which was the main 
in-store, or first user demonstration program for the Apple II. 

Bruce started out ~ well, I don't know where Bruce started out, but when we encountered Bruce Tognazzini in his long and 
checkered career, he was the proprietor of a computer store in San Francisco, which is where the Apple Corps of San 
Francisco used to meet. And that's how he got into the Apple community, by selling Apple computers. So he had front line 
experience in what happened when a person encountered a personal computer for the first time. When he came to Apple he 
started writing demo programs with J. D. Eisenberg. And one of the things that they did was, they tested on real users in real 
situations, where you bring somebody who's never seen a computer before, much like the Lisa group was testing people off 
the street, or new employees, put them in front of this program and gave them no advice whatsoever. 

I'm going to read ~ Bruce tends to philosophize a lot in this, so it's not going to be as useful to put up slides, but I'm going 
to read to you some of his experiences from the ~ here we go. From user testing: "Our testing method is as follows. We set 
up a room with five to six computer systems. We invite groups of five to six users at a time to try out the systems, often 
without knowing that it is the software, rather than the system, we are testing. We have two of the designers in the room: 
any less, and they miss a lot of what's going on; any more, the users feel as though there's always someone breathing 
down their neck. The initial ground rules are that no questions will be answered, as by the time the formal testing begins, we 
can supply a draft of the manual. Usually by the second group, some glaring defects in the interface have shown up, and 
we have to give them help getting past the stumbling blocks. 95 percent of the stumbling blocks found are found by 
watching the body language of the users. Watch for squinting eyes, hunched shoulders, shaking heads, and deep, heartfelt 
sighs." [Laughter] "When a user hits a snag, he will assume it is his fault He will not report it. He will hide it. Make notes of 
each problem and where it occurred. Question the users at the end of the session to explore why the problem occurred. You 
will often be surprised what the user thought the program was doing at the time he got lost." 

"Herein follows a true anecdote which illustrates how difficult the most simple human interface issue can be, and why 
thorough testing on real people is so important. As we tune in" ~ it's so easy to entertain a crowd just by reading something 
Bruce wrote [laughter] ~ "as we tune in, the authors of the software, both of whom pride themselves on clever interface 
design, have anguished for hours over difficult passages in their program. It was to turn out, their guesses were quite 
accurate in said difficult passages. It was the simplest question of all, the cause of the problem. In Apple Presents the 
Apple II E, the training program for teaching fundamentals using the new Apple II E, find out if the user is working with a 
color monitor. 

"User profile: new owner, customer in computer store, or member of a class learning how to use an Apple computer. Test 
user profile: customers in computer store, non computers [users?] in classsroom environment, friends and relatives. First 
design: a color graphic is displayed on the screen. Prompt: are you using a color TV on the Apple? Anticipated problem: 
those who were using a monochrome monitor in a classroom or a computer store situation wouldn't know whether the 
monitor was black and white, or was color with the color turned off. First attempt: a color graphic's displayed, prompt: is the 
picture above in color? 25 percent failure rate." [Laughter] "Reason: as anticipated, but incorrectly overcome, those seeing 
black and white thought their color might be turned down. They didn't answer the question wrong, they turned around and 
asked one of the authors whether the monitor in question was color or not. A decision was made: the authors could not be 
supplied with the disk." [Laughter] 

"Second attempt: a smaller graphic, with large letter words in their own vivid colors, was substituted: green, blue, orange, 
magenta, which were the only colors the Apple II can display. Prompt: are the words above in color? Failure rate: color TV 
users, none; black and white monitor users, none; green screen monitor users, 100 percent." [Laughter] "This is why it pays 
to have a variety of configurations in your test suite. Third attempt: the graphic remained the same, prompt: are the words 
above in more than one color?" [Laughter] "Failure rate: color TV users, none; black and white monitor users, 16 percent; 
green screen monitor users, 50 percent. Reason: the black and white monitor users who answered incorrectly admitted they 



green, two colors, and answered the question accordingly." [Laughter] 

"Fourth attempt: same display of graphic and color text. Prompt: are the words above in several different colors. Are the 
words above in SEVEFIAL different colors? Failure rate: color TV users, none; black and white monitor users, 20 percent; 
green screen monitor users, 23 percent. By this time the authors were prepared to supply everyone who bought an Apple 
with a free color monitor just so we would not have to ask this question." [Laughter] "It turns out about 20 percent of the 
people were not really reading the question, and were responding to 'Are the words above several different colors?' 'Well, 
yes, of course, green, violet, red, there are several different colors, let's move on!'" [Laughter] 

"Fifth attempt: same display of graphic and color text. Prompt: do the words above appear in several different colors? 
Failure rate: none. In case it appears the authors were simply dull fellows, be it known that this was a fully interactive 
training program, in excess of 100K of code," — remember, it was a 128K machine, so ... - "and this was the only interface 
issue that required more than one correction. It clearly exemplifies how even the most careful designers can totally miss 
when guessing how users are going to respond." So, reading from Bruce Tognazzini. 

The Apple II project had started out ~ well, the Apple II wasn't really a project, it was a collection of projects. We started out 
with a number of pieces of software that had our cherished angle bracket or square bracket prompts. By the time we got 
around to the Apple II E and the Apple III, we'd developed a more or less text windowing interface, called File Card 
Metaphor, where we used special characters in the character generator ROM to do something like the File Card interface in 
the Lisa, with ~ pick one, two, three, four, five, six menus, and you used the escape key to back out through a hierarchy, 
and press numbers 1, 2, 3, 4, 5, 6 to advance to the next level. It was a hierarchical-spatial text-driven, keyboard -driven 
user interface. It didn't use the mouse. It was very successful for what it did. We ensured consistency across many 
applications, all the applications that Apple implemented as well as third party applications. For example, if anyone was 
familiar with Quark Catalyst ~ Quark, they're the people who make Quark Express now, they made the original Hard Disk 
Manager for the Apple II and the Apple III, and it used the same interface. It had consistent use; in the keyboard keys, the 
Open-Apple always meant the same thing in different applications. And so even though it was a text interface, it had many 
of the underpinnings of the consistency of the graphic user interface of the Macintosh. And it was driven by the exigencies 
of User Training, which was my mother's group, because the less time we had to spend on user training, the cheaper and 
faster it was, and if the software were consistent, the training went more easily. 

It was driven by the exigencies of Publications, which I was running, and one of the problems we faced in Publications was 
that having not invented desktop publishing yet, we had six weeks minimum from film to printers, which was usually the time 
that was reserved to write or finish the software. We often had to be finished with the manuals several months before the 
product shipped, and the software wasn't finished at that point, so in order to have manuals that accurately reflected what 
the software was going to do, we had to have the programmers tell us what the user interface was going to be, and then in 
going through that with the programmers, having them do it the same way other applications did it gave us a more full idea 
for "okay, it's going to do this, it's going to do this, it's going to do that," if they followed some standards or some guidelines. 
In fact, what Bruce did before writing the Apple II human interface guidelines, and what the origin of this document was, was 
in fact a Publications Style Guide, which was how we wrote manuals and how we explained portions of the human 
interface, and explained portions of how you used the computer. And by using consistent explanations, that drove consistent 
design in some of the applications. 

So that was in the origins of user testing and of consistency of user interface design in the Apple II group. As I said, it 
moved into the Lisa group, starting with the separate angle which Larry talked about, coming from Xerox PARC. And the 
two basically fused in the Macintosh group, where we had the Lisa ~ the benefits of the years of Lisa user testing 
experience and the massive amounts of design that went into the graphic user interface, plus a lot of the democratic, 
grassroots issues that had come up through the Apple II. Remember, Lisa was only dealing with seven applications. That 
was all you got on a Lisa. The Macintosh was designed like the Apple II with something where you had many, many 
applications from third party developers. And so we took the Lisa user interface, grafted it on to the guidelines that had 
come out of the Apple II Style Guide and Apple II guidelines efforts, and published that for third party software developers to 
use as style guides for their own applications. 

I remember very, very, very clearly that one of the massive controversies around the development for the Macintosh, circa 
1982-1983, was developers would come up to us and say, "You know, if you make the user interface consistent, and if you 
put all that software in ROM that makes it ~ you know, if you make it hard to write to the screen directly, so that we have to 
use your user interface software to talk to the user, how are we ever going to make our applications unique, and stand out, 
and be different from each other in the marketplace?" They found a way, I'm very happy, but the human interface and the 
idea about consistent human interface, much less a graphic one, was very, very controversial among software developers. 
And only by having the user testing under our belt to show them that hey, this is going to add significant value to your 
product, by making your product easier to learn and easier to use, especially for people who already know another 
application, were we able to really convince them that a consistent graphic user interface was a good thing to have. 

I want to fast-fonward a little, skip through the early years of the Macintosh and go to a tape that I dug up from the Apple 
library, of some user interface testing that shows how amusing user interface testing can be, and the kinds of situations in 
far-flung places that members of our glorious user interface group went, to find the truth about what real users would do. 
This is a tape of a couple of our user interface designers, Lauri Vertelney and one other person, I may come up with her 
name. [Inaudible comment] I don't think it was Gitta. Traveled to France to a parts dealership for Renault automobiles, who 
were deploying a new automotive parts catalog based on HyperCard, HyperCard being a free-form tool kit for designing new 
software interfaces. [It] presented an entire raft of new problems in human interface design. They actually went to France to 
test auto mechanics in their own environment. I'm going to play that tape for you now. 

[Q, while videotape is being set up:] Was the name Kate Gomoll, is that right? Do you know the name? 

CE: It might have been Kate Gomoll, yeah. Thank you, Annette. Was that Annette? [Inaudible reply] Oh, it's Joy. Hi, Joy. 

[VIDEOTAPE PLAYS] 

"The first part of the user test is to test users attempting to fill out the order form and the estimate form, using the current 
paper methods. These are the order and estimate forms that the mechanics currently use. The [inaudible] part catalog is 
used to look up parts information. And the repairmen will have instructions on how to [inaudible] car. Kate's going to test the 
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doesn't speak French. [Several sentences in French.] If you have trouble with some of the tasks, it's the system's fault, not 
yours. [More French sentences.] [Inaudible] Kate suggests that we have us evaluate the results later, [inaudible] after the 
test session. Seeing the mechanic work with the paper helps us to understand how he prefers to get Information. For 
example, he stacks the forms on top of the catalog, and flips the pages while he's searching for information. Research 
techniques helped us to submit one recommendation for searching with the electronic version [inaudible]. Once we have 
finished testing the current form [inaudible] procedure, we ask the mechanic to solve the same problem with the 
documentation for the electronic system. 

"At this point in our test the user has tried for over two minutes [inaudible] to start the system. Kate finally instructs the user 
he must click on the tiny icon below the Renault logo to start the system. The interpreter wants to know if he should explain 
the popup menu that [inaudible] below the startup icon, and Kate says no. When he clicks on the icon he knows nothing 
about how to use popup menus, and initiate the dialog box, which explains to him he needs to hold down on the icon. Of 
course, the mechanic's never seen a dialog box before, and is confused, not only about the message inside of it, but what 
to do with it. Finally he realizes he must click on OK to get rid of it. [Inaudible] he tried to stop the application and click on 
any of the buttons in the menus in the left of the screen. Unfortunately, none of the menu items worked at this point, 
because he had not filled out the appropriate vehicle identification, to actually start a work session. He tries the small icon in 
the center of the screen [inaudible] the dialog boxes telling him to hold down on the icon. This time he doesn't see that he 
must click on the OK boxes, but he's clicking around the screen [inaudible] Finally Kate instructs him to hold down the 
button in order to start the program [inaudible].... hold down the OK button in the dialog box." [Laughter] 

"We tried testing the dialog [inaudible], one more time. But, [inaudible] the dialog box. [Inaudible] the OK button [inaudible] 
.... the popup screens are not going to work." 

[END OF VIDEOTAPE] 

So, that just, I think, is an illustration of two things. One, that bad design knows no bounds. And two, that you never get a 
user interface right, and that user testing, from the earliest times when you have a totally unsaturated market ~ people who 
have never seen personal computers before, much less mice, keyboards, screens, things like that ~ to today, when we 
assume that anybody who's ever been in western society has had to have encountered a personal computer at some point, 
and knows the basics of pointing, clicking, dragging, pressing, what a file is, what a document is, how to print, why to print, 
what a floppy disk is. I still find it surprising that we don't talk about sectors and cylinders any more on disks, which was one 
of the main things we had to explain in 1978, 1979, because there was some reason you needed to know that, I forget why. 
[Inaudible comment] Yes. But that some things never go away, and that having to test new designs, and test your 
assumptions of what your audience knows, is pretty much eternal. 

So, at that point, having run pretty late, I think Larry and I will take a few questions, and I think that we're going to take free 
liberty to defer to several people in the audience who are noted in Apple human interface history. I see Joy Mountford and 
Annette Wagner back there, who've been instrumental in human interface groups in the past, and if there are any others, 
and if you have strong opinions, disagree with us, have more information than we're able to supply, please chime in. And 
Larry, do you want to pass the mike around, so people can ask questions in the mike? 

LARRY TESLER: [inaudible] to repeat the question. 

Q: Larry, I wonder if you could comment on the story that's often told, that Apple ripped off the Xerox PARC work. I know 
Jef Raskin has refuted or denied that, but it's such a popular story, could you go on record as giving your perspective? 

LARRY TESLER: Yeah. Well, I actually showed, at the beginning of the talk, a picture of the Smalltalk interface, to see that, 
in fact, the early user interface designs were very close to that. The look of the windows, in particular, and the icons and the 
desktop. But it evolved over time, and the menus moved to the top of the screen, and so on. If you actually look at either a 
Xerox Star or a Smalltalk screen, and then look at a Lisa or a Mac, I think you'll see a lot of differences. What was taken 
was the concepts. The concepts that there ought to be overlapping windows, that there ought to be direct manipulation, and 
so on. But the Xerox Star, for example, didn't have the concept of dragging things. And it had a two-button mouse, you'd 
click one place and then click another place. It didn't have a menu bar. In fact there was only one menu, that was added 
late in the development. Some things were similar; there was a horizontal and a vertical scroll bar. So certainly the concepts 
came largely from there, but as you see, some of the concepts came from other things: from HP systems, UGSD, from 
Apple II, from some work that was done at IBM that I didn't talk about today, that was published around the late TO's. So, 
there were a lot of origins for it. I think the Xerox work had a lot to do with it, but usually when the ~ if you sat down to try 
to use a Star or Smalltalk you would find that there were I think more differences than similarities in what you would actually 
see and do. 

Q: [Inaudible] 

LARRY TESLER: The question is, the user testing we showed for the Lisa had to do with novice users, and the question 
was whether we tested for how people acculturated over time. Well, the system, remember, from the very first page of the 
user interface guidelines Bill wrote was targeted at novice users. That was the target, which was about everybody in those 
days. And we did have some theories about how people would use command keys as they got more expert and so on, but 
we didn't run user tests. One reason we didn't was because it would have taken a long time to get people up to speed. So 
what we did was, we just used kind of ourselves. I don't mean the engineers, but people who worked in the Lisa division, 
who had Lisas, like people in Product Marketing. They became expert after a while, and they would start telling us that 
things were too slow, or too hard, or whatever. And that's how we got that kind of feedback, just from people inside. I think 
it's more relevant today to check for those sort of things than it was back then, when everybody was ~ you know, 95 percent 
of the people were novices. 

CHRIS ESPINOSA: One of the constant tensions, and this was true on the Macintosh as well, especially because we had 
the benefit of the Lisa work before us, and some of the Lisa machines, the constant tension is that people who are 
designing are almost always by definition expert users, and will often overlook that what they think is obvious is not at all 
obvious to a novice user. And so there's constantly the dilemma which you've seen historically in Mac system software, that 
the expert users want to put in the features they want to use, but the people who want to keep the system pure for the 
novices want to resist those, and if you're lucky you get a system that is easy to approach for the novice, and gradually 
unfolds itself for the expert. And if you're unlucky you get a lukewarm mediocrity between the two, where it's a little too 
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designs, and some of the industry designs, have been gradually unfolding, and other have been just plain mediocre. 

Q: I have an observation and then a question. Larry and I have known each other for years, from Xerox days. And it's 
interesting to me that, for one thing, you folks weren't aware of the similarity to the Wordstar commands that already existed, 
in the Wordstar editor, for Copy, Cut, Paste kind of things. But also I think the word "assumption" is key and what you just 
said is very correct. People assume as they're developing something that they know the best way to develop it, rather than 
go outside and get other information. One of the things that I've seen as a software person in the past, having to do work 
for people for money, so that they expect us to have something done by a certain time, not for a company that I'm working 
for but as a consultant, is that they really do expect the thing to work the way their people want it to work. And there you 
really have to do a design review, and all sorts of things with those people first before you get to the right setup, before you 
can actually start writing code. And one observation about the Lisa that was very interesting, when I first saw it ~ I first saw 
it, I think, at the West Coast Computer Faire in San Francisco. Steve Jobs was there, I don't know who else from Apple was 
there, other than Marketing staff. But I'd gone there with a friend from Xerox. And we looked at the Star system. And we'd 
actually looked at the Fortune system, which was the first 16-bit personal computer that was available. And they had a very 
fancy display, and so forth, and everybody was looking at it; it was beautifully designed, and everything. Everything else that 
it ran CPM and UNIX, a version of sort of UNIX. There was one test in the software work that we had done, for real 
customers, who really wanted reliable software, that we'd accidentally come upon which was called the "keyboard mush." 
You take your hand and you run it across the keyboard a few times, and you see if your software is still running. [Laughs] 
And I told this friend of mine from Xerox about it. So he walks over to the Fortune system, on the big podium up there, with 
the pretty girls standing by it, and he tries it. And the thing dies. So we kind of sneak away, and we go over to the Apple 
booth, and there's Steve and the other folks there. And we decided we weren't going to try it on a Lisa. So in reaching for a 
brochure, though, I accidentally touched the upper right portion of the Lisa keyboard. They were networked at the show, for 
a demonstration of networking. It brought down that Lisa. The guy helped me try to reboot it. It wouldn't come back. It also 
brought down all the other machines at the booth, on the network. And the only thing we finally could do was to power 
cycle the whole system. [Laughs] So I just wanted to bring that out. I just wanted to bring out the basic nature of testing, 
which involved looking for the unforeseen. 

LARRY TESLER: Ah., looking for the unforeseen. Right. Good point. In the interests of time, we're going to keep the 
comments shorter, though. 

Q: Do you see any relationship between [inaudible] and the graphical user interface [inaudible]? 

LARRY TESLER: Yes. The question is whether there's some correspondence between the object oriented programming 
metaphor and the user interface metaphor. And yes, there is. In fact, in the Smalltalk user interface, which was one of the 
first of this type, and the Smalltalk language, which was one of the first of the object oriented type, the connection was very 
explicit: that you had objects that had generic commands that could operate upon them. And that was something that 
existed both in the language and in the user interface. Which was done even more so in the Star. But the programmers who 
were doing these user interfaces definitely had that in mind, as a correspondence. 

Q: [Inaudible] a comment on the first [inaudible] counterexamples [inaudible] user interfaces before their time. Graphical 
user interfaces that had nothing to do with object oriented programming languages. 

LARRY TESLER: Oh, yeah, good user interfaces don't have to, I'm just saying that the user interfaces that we were 
developing, we had that in mind. But that doesn't mean that a good user interface has to be object oriented, no. 

Q: You showed two years of memos that you had written and received. Having come from an environment with the Alto, 
Bravo, Gypsy and [inaudible], what did you write all those on? 

LARRY TESLER: What did I use to write the memos? Probably Apple Writer, let's see, early on we were using ~ maybe 
Apple Writer on the Apple II, or maybe UCSD Pascal program editor being abused on an Apple II. I never had an Apple III. 

CHRIS ESPINOSA: You're right, you were probably using either Apple Writer on an Apple II, or sophisticated people used 
the UCSD Pascal editor and output it using an NROFF-like program called Apple Script [LARRY TESLER: Right] and we 
output it to Qume printers when we could afford the time and noise, and to dot matrix printers, 80-column dot matrix 
printers, and you had a mix of those two. Before we got the Apple ll's and Apple Ill's up, Jef Raskin had imbued us with 
Polymorphic Poly 88's, using their editing system, and we did all of our editing on Poly 88's, Soroc terminals. 

Q. Back in the, probably 1983-1984 time frame, Digital Research had a graphic interface called GEM. That sort of got 
buried in litigation of some sort. Can you comment on that whole story from Apple's side, and speculate on what might have 
happened if Digital Research didn't [inaudible] part? 

LARRY TESLER: Well, I don't know about successfully competing in that part. But yeah, it was extremely close to the Mac 
user interface, the GEM user interface by Digital Research. And Apple sent some kind of complaint letter, and there were 
some discussions between the companies. But then Microsoft and Hewlett Packard started doing Windows and New Wave, 
and that was a much bigger issue, so Apple kind of stopped bothering Digital Research and instead got involved in a big 
law suit with HP and Microsoft. Digital Research at the time was kind of a struggling company, and Apple didn't want to 
basically pick on a little company. Instead, we picked on two companies that were too big [laughter] instead of picking on 
one that was too little. Bernard? 

Q: Would you like to comment on the fact that both Lisa and the Xerox product [inaudible] ? 

LARRY TESLER: Yeah. Like the Xerox Star? And the Lisa — the idea was, in both groups, was that people would only use 
a few applications. It's kind of true, most peopie oniy do use a few applications. But the conclusion that, therefore, it wasn't 
necessary to have third party applications was kind of ridiculous. Actually in the Lisa, it turned out we did have a place for 
third party applications. We thought for certain vertical markets, there would be third party applications and we'd have 
accounting software and so on. But even then, we were thinking very small scale, like there would be one page layout 
application, and there would be one accounting application, and a couple of vertical market things. If we ever had 20 
applications, or 30, that would have been a very large number. Very different from the Mac, which from the very beginning 
was going to try to do the same thing as the Apple II, and what the IBM PC did, which was go for lots of third party 
applications. I think one reason the Lisa was designed as it was, was to try to justify why there was this project going on in 
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Apple III were going to have all this third party software, but the Lisa won't. It was kind of a differentiator. It was a kind of a 
closed system that was supposedly a plus. It turned out to be a major minus, of course. 

CHRIS ESPINOSA: Well it was — that was not necessarily unique to Apple at that point. Remember one of the leading 
software companies of 1979 -1980 was Personal Software, which became Visicorp. And their flagship product line at that 
point was a failed product line called VisiOn, which was an attempt to expand VisiCalc into a comprehensive suite of 
interacting applications ~ a word processor, a data base. Wordstar at that point was also trying to expand. Everybody was 
trying to do what Microsoft has successfully done with IVIicrosoft Office, which is turn the thin end of the wedge of getting 
one successful application, which IVIicrosoft had with Excel on the Macintosh, and turn that into a major suite that delivers all 
of the application computing needs of the given set of users. Microsoft has done it successfully, and one could argue that 
the default computing platform right now is Windows with Microsoft Office, and not very much else. So I don't think that that 
necessarily was a bad idea. It may have been many years ahead of its time. But Microsoft was selling the Microsoft Office 
for Macintosh in 1985. I still have a box on my shelf where they supplied the word processor, the spreadsheet, the filing 
program and the terminal program in one box, for one price, for the Macintosh. So, office suites certainly were not a dumb 
idea of 1981; it's something that has really monopolized the industry. 

LARRY TESLER: Yeah, I think that part's true. The Lisa was really one of the first suites, in addition to the ones that 
Personal Software did. It was the first, probably, multitasking personal computer. But basically ahead of its time and missing 
the main point, which was, you needed a low cost platform that had reasonable performance and that had lots of third party 
applications. 

Q: You were testing totally naive users without any instructions, by and large. And yet, in the intervening years, acculturation 
has taken place, and I wonder if that really helps us [inaudible]. 

CHRIS ESPINOSA: The point is that we were testing in the early years for totally naive users, and that over the years 
acculturation has taken place, as I talked about. More people approach computers with less fear, with more pre-knowledge 
of what they're doing. Is that your general point? 

Q: Yes, and that pre-knowledge came from a process of about [inaudible]. 

CHRIS ESPINOSA: And the process came from a decade or more of experimentation. Well, I'll tell you about an interesting 
user experiment that I did. In 1982, I took a[n] early prototype of the Macintosh, and it was then in a Plexiglas case, just cut 
panels of Plexiglas, filed and glued square — we didn't have any of the injection molded cases yet — with the guts inside. It 
was running an early version of Mac Paint, which was called Mac Sketch at that point. And it was a turnkey application: you 
put the disk in and you booted it up and it went straight to that application, because there was no Finder at that point. Which 
was actually the paradigm of most other machines, which was turnkey boot: you put the floppy in and you booted it and you 
got into that one application. And I took it over to my girlfriend's parents' house for Thanksgiving, where she had a three 
year old nephew. A three year old nephew, and this was in 1981. Video games weren't even that — hadn't even gotten down 
to three year olds by 1981. That boy spent four hours drawing with Mac Sketch. He learned it in no more than 15 or 20 
seconds, just, you press the button and draw things on the screen. And he was drawing things with an early version of Mac 
Paint, with virtually no tutoring and almost no language at all. With no acculturation at all. So, there were some things that 
we got basically right, about "human" human factors. If you can appeal to a three year old, and get a three year old with no 
language skills to understand how to do something productive in no time at all, that's not a cultural statement. You've done 
something right in design. And that's when I knew we were really on to something. 

0: ... the acculturation has no affect? 

CHRIS ESPINOSA: I don't think it's had no affect. I think what acculturation has done is, it's made us soft. We don't address 
complexity any more the way we — we sweated over complexity, in 1981. We were deathly afraid of complexity. We take it 
for granted now. You look at Frye's. It's scary, the kind of things we get away with. 

LARRY TESLER: I think it has made some things hard to change. When Microsoft announced they were going to go to 
single clicks instead of double clicks on the desktop, some journalist said, "See, they're leaving Apple in the dust. You're still 
on two clicks, and they're moving to one." I said, "Our users have been doing this for 12 years. There's no way they're going 
to change. We're never going to change it. Maybe the Microsoft users, who have only been doing this for a couple of years 
can change." But as it turned out, even a couple of years using Windows 95 was too much, and Microsoft had to back off on 
making users use single clicks, in Windows 97, because even two years was too much. People won't change. 

We're out of time now, but there are some people here who were involved in Lisa user interface work, all the way from the 
Apple II, the Lisa, and the Mac. I thought maybe they could stand up. Annette Wagner specially, who worked on the original 
Lisa look, and graphics and fonts and everything. And Joy, and Bob — why don't you all stand up, all you Apple interface 
people. I think some of the users out here might appreciate you. Bob Glass, still here? [Applause] 

LEN SHUSTEK: Thank you both for a great talk. I hope you'll join us over in the warehouse, just down the street to the 
right, and Larry and Chris, will you both be there to answer questions? Great. Thank you for coming. See you next time. 
[Applause] 

[END OF VIDEOTAPE] 
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